The Web is becoming more interactive than it has ever been before. It is now possible to implement synchronous video conferencing applications running in a web browser either using plug-ins or new Hyper Text Markup Language 5 (HTML5) Application Programming Interfaces (APIs) which will become widespread in a near future. Eventually, this will make it possible to implement cost effective and highly customized solutions for various vertical markets—for example e-health—rather than having to use a big, generic, one-size-fit-all horizontal solution.
While video and audio conferencing running in a web browser makes it possible to communicate in new ways, it essentially turns a web browser, executing a customized collaboration application, into a synchronous communication platform. This also leads users to expect that other user interface components managed by the collaboration application also form a part of the communication. For example, in an e-health application, users may want to share items like diagrams, pictures, sensor data, text documents or even run web applications together with peers, e.g. other users, in a conference session. A natural complement is, therefore, some kind of synchronization framework that allows the users to share the items managed by the collaboration applications with each other.
An example of a collaborative web application framework is called
Distributed Shared Memory (DSM) framework. The DSM framework makes it possible to synchronously share data of a web application in real-time with other users. This is possible since the DSM framework provides a memory, or data storage, that can be shared between web applications. In short, the DSM is a distributed global addressable memory space where every memory space is assigned a unique address. By knowing this address, it is possible to get a copy or reference to that memory.
In FIG. 1, a schematic block diagram an exemplifying implementation of DSM is shown. In this example, an exemplifying DSM Server 1 manages a DSM Master 2, referred to as memory or data storage above. Each of two DSM Clients 3, 4 manages a respective DSM Replica 5, 6. Moreover, each of the DSM Clients 3, 4 comprises a respective User interface 7, 8 for interaction, by a user equipment, with the respective DSM Replica 5, 6. Hence, in this example each DSM Client 3, 4 acquires the DSM Replica 5, 6, i.e. a local copy, of the DSM Master 2 and then synchronizes each of the DSM Replicas 5, 6 when needed. Synchronization is needed when contents of the DSM Replicas 5, 6 differs from contents of the DSM Master 2. Any modification to a particular DSM Replica 5, 6 is synchronized so that every DSM Replica converges to the same state after some time. At start up, the DSM Server 1 creates the DSM Master implicitly if requested by any DSM Client. Moreover, when no DSM Client is connected to the DSM Master, the DSM Master is automatically garbage collected. This means that any memory allocated by the DSM Master is no longer locked to the DSM Master.
As an example, a developer may use Web Connectivity, which is an API framework, to create an overlay network in the application layer. In the overlay network, applications, running in any context, have a uniquely addressable Unique Resource Identifier (URI). These applications may act as servers in the overlay network. These URIs are uniform for the application, regardless of whether it runs on a server or client, native or browser. One use of the Web Connectivity API is to create, on the fly, a server in a web application, which is executed in a runtime environment of a web browser. Once the session ends, and the user navigates away from the current page, the server is shut down and becomes inaccessible. It shall also be said that Web Connectivity is sometimes referred to as Warp.